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Description 

Field of the Invention 

[0001] In computer networks, routing protocols are 
used to distribute inlormation that allows to determine 
how to send a data packet or a message from any point 
in that network to its intended destination. In many cas- 
es : a data packet or message is sent from a single 
source, the sender, to a single receiver; this is usually 
called unicasting. Today's computer networks have 
elaborate routing protocols to support or assure safe, 
fast, and reliable execution of such unicast transmis- 
sions. If a data packet or message must, however, be 
sent from a single sending source to a group of receiving 
stations within a network - usually called multicasting - 
it is very inefficient, if at all possible, to rely on traditional 
unicast routing protocols for this purpose. For this, the 
present invention provides a solution; it relates to mul- 
ticasting, in particular to a method of multicasting mes- 
sages in a complex network that is originally equipped 
only for unicast transmission. 

Background and Objects of the Invention 

[0002] Existing state-of-the-art routing protocols, 
such as the Inter-Domain Routing Protocol (IDRP), as 
disclosed e.g. in ISO "Information Processing Systems 
- Telecommunications and Information Exchange be- 
tween Systems - Protocol for the Exchange Inter-Do- 
main Routing Information Among Intermediate Systems 
to Support Forwarding of ISO 8473 PDUs\ ISO/DIS CD 
10747, 1991, being standardized by the International 
Standards Organization, ISO, provide a framework for 
routing unicast packets, that is, packets sent to a single 
destination. 

[0003] Often, a key requirement of computer net- 
works in general, and of applicant's Multi-Protocol 
Transport Network (abbreviated MPTN in the following) 
specifically, is to allow to multicast data packets, which 
are sent from a particular source to a group of destina- 
tions. Generally speaking, this invention gives a solution 
to this requirement by teaching a method of and a sys- 
tem for multicasting using a set of new protocols in com- 
bination with existing routing protocols (e.g. IDRP) to 
support multicasting in a computer network of arbitrary 
size and topology. It has characteristics which make it 
suitable for such an environment that are not found in 
any existing multicasting protocols. 
[0004] In the following, background and objects of the 
invention shall be described in more detail. It should be 
understood, however that the invention is not in any way 
restricted to be used within the type of network de- 
scribed hereinbelow. Further examples can be found in 
other parts of the description. 
[0005] A widely used protocol set such as IBM's Multi- 
Protocol Transport Network provides connectivity to 
computer applications, regardless of the network to 



which they are attached. Thus, as illustrated in Fig. 1, 
two applications attached to different subnetworks in the 
same MPTN 11 can communicate. As shown in Fig. 1, 
a client application 12 attached to a first subnetwork 13, 
s e.g. a NetBIOS subnetwork (a trademark of the appli- 
cant), can communicate with a compatible server appli- 
cation 14 attached to a second subnetwork 15, e.g. a 
System Network Architecture (SNA, which is also a 
trademark of the applicant) subnetwork. MPTN gate- 
70 ways 16 and 17 are required to join the three different 
subnetworks 1 3, 1 5, and 1 B into a single logical network 
(the MPTN): the gateways are connected via the third 
subnetwork 18, e.g. a Transmission Control Program/ 
Internet Protocol (TCP/IP) network. 
is [0006] A key function of the MPTN gateways 16 and 
1 7 is to route messages Irom their source (e.g., the client 
application 12) to the destination (e.g., the server appli- 
cation 14). This problem is difficult for the lollowing rea- 
sons. 

A path between the source and destination must be 
found that satisfies the requirements of the applica- 
tion (e.g., security, speed, reliability). 
The MPTN may be very large, with many subnet- 
works and gateways. This can result in a very com- 
plex network topology, and therefore complex rout- 
ing decisions need to be made at the gateways. 
Due to link and node failures, or the installation of 
new equipment, the topology, and thus the correct 
routing decisions, change in real time. 

[0007] To solve these problems, MPTN gateways 
make use of the routing protocol mentioned above that 
was standardized by the International Standards Organ- 
ization, called the Inter-Domain Routing Protocol (ID- 
RP). IDRP defines the formats and procedures of a pro- 
tocol for routing from a single source to a single desti- 
nation in a network of arbitrary topology and size. How- 
ever, IDRP does not support multicasting, that is, deliv- 
ery of a message from a single source to multiple des- 
tinations. On the other hand, multicasting is essential in 
MPTN for a number of reasons. First, some subnet- 
works support multicasting and, therefore, applications 
running on those subnetworks take advantage of this 
feature. In order to provide connectivity to such applica- 
tions, multicasting must be supported in the internet- 
working environment. Second, some MPTN control pro- 
tocols are based on multicasting. For example, proto- 
cols for locating a resource require that a search for that 
resource be distributed to all gateways attached to sub- 
networks in which it might be located. 
[0008] Some examples of the problems associated 
with multicasting in an internetwork environment are 
now described making reference to the simple MPTN 
illustrated in Fig. 2. In this example, a multicast is initi- 
ated by an application in subnetwork W (21 ) that should 
be delivered to destinations in subnetworks X .(22) and 
Z (24). There are no destinations in subnetwork Y (23). 
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The problems associated with such an operation in- 
clude: 

It is not acceptable to generate separate (unicast) 
messages to all destinations since this would create s 
an unnecessary load on the MPTN resources. For 
example, in Fig. 2, such a unicast strategy would 
necessitate that one message for each destination 
be sent on the link between gateway A (25) and 
gateway B (26) instead of just a single multicast io 
message. 

It is not acceptable to multicast the message to eve- 
ry subnetwork in the MPTN. In the example, sub- 
network Y (23) should not receive a multicast des- 
tined only to nodes in subnetworks X (22) and 2 is 
(24). Although not illustrated by the example, it is 
clear that in a large MPTN with many subnetworks 
and many different multicast groups, such a flood- 
ing strategy would not be acceptable. 
A given packet should only be multicast once to a 20 
given subnetwork. In the example network, there 
are two paths from gateway B (26) to subnetwork X 
(22), via gateway D (28) and via gateway C (29) di- 
rect. Subnetwork X (22) should, however, only re- 
ceive a single copy of the multicast from the source ss 
in subnetwork W (21 ). This rule must hold regard- 
less of the number of gateways attached to subnet- 
work X (22), or the number of paths between a 
source and a particular destination subnetwork. 
This is important to minimize the load placed on 30 
subnetworks due to multicast traffic, and to avoid 
duplication of packet delivery which may necessi- 
tate error recovery protocols for some applications. 



bridges, these can selectively filter LAN messages so 
that they are only broadcast on segments where at least 
one node is a destination for a multicast. These proto- 
cols work as follows (see Deering and Cheriton, cited 
above, for variations on this basic algorithm): 

1 . Group members broadcast their existence on the 
LAN to which they are attached. These broadcasts 
are forwarded by bridges onto all LAN segments so 
that all bridges can learn the location of group mem- 
bers. 

2. When a multicast packet for a group is received, 
only bridges on the path to one or more members 
of that group forward the packet. Thus, flooding of 
all LAN segments for each multicast is avoided. 

[0012] A restriction of such LAN-based multicasting is 
that no loops are allowed in the topology, i.e. there can- 
not be multiple paths via bridges between any two LAN 
stations. This is required since otherwise the simple for- 
warding scheme used by the LAN bridges would result 
in packets being broadcast forever around any such 
loop. Such a scheme is unsuitable for multicasting in a 
large internetwork since all traffic would be forced to 
take the same path through the internetwork thereby 
creating an unacceptable load on the involved links. Al- 
gorithms exists which allow loops to exist in the LAN to- 
pology, but a single set of bridges is selected that form 
a loop-free spanning tree for forwarding multicasts. 
Thus, all multicast traffic is still forced to follow a single 
path along the branches of the spanning tree. 

Multicasting In the Internet 



Prior Art 

[0009] For a better understanding of the invention, so- 
lutions for multicasting messages in other environ- 
ments, and existing solutions in internetworking envi- 
ronments will be reviewed. 

Local Area Networks (LANs) 

[0010] LANs are a very special type of subnetworks 
since they naturally support a broadcast function, such 
that a single message is easily delivered to all nodes. 
The most common LAN multicast strategy is therefore 
to broadcast messages, and let each attached computer 
filter those messages not required by local users. An ex- 
ample is given by S.E. Deering and D.R. Cheriton in 
■Multicast Routing in Datagram Internetworks and Ex- 
tended LANs - , ACM Transactions on Computer 
Systems , Vol. 8, No. 2, pp. 85-110, ACM, May 1990. 
However, such a strategy seems unsuitable for a large 
internetwork, as previously explained. It should also be 
mentioned that essentially the same observations hold 
for Metropolitan Area Networks (MANs). 
[0011] When LAN segments are interconnected by 



35 [0013] Multicasting algorithms exist that work with 
routing protocols used in Internet Protocol (IP) net- 
works. IP networks provide routing and relaying of pack- 
ets (called datagrams) over a general topology network 
consisting of LANs, point-to-point links, and even sub- 

*o networks such as X.25. An IP internetwork consists of 
a collection of such subnetworks interconnected by IP 
routers. 

[0014] The following routing protocols used in IP net- 
works are all based on a distance-vector (sometimes al- 
« so called path-vector) routing scheme like that used in 
IDRP: 



Routing Information Protocol (RIP), as described by 
C.L. Hedrik in "Routing Information Protocol', RFC 
1058 (Request for Comments), NIC (Network Infor- 
mation Center), June 1988. 
Hello Routing Protocol, disclosed by D.L. Mills in 
•Experimental Multiple Path Routing Algorithm", 
RFC 981, NIC, March 1986. 
Border Gateway Protocol (BGP), described by K. 
Lougheed and Y. Rekhter in "Border Gateway Pro- 
tocol (BGP)", RFC 1163, NIC, June 1990. 
Gateway-Gateway Protocol (GGP).as disclosed by 
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R.M. Hinden and A. Sheltzer in "DARPA Internet 
Gateway", RFC 823, NIC, September 1982. 

[001 5] As will be apparent later, the present invention 
provides a solution directly applicable 1o all networks s 
based on the above (and equivalent) routing protocols. 
[0016] IP multicast algorithms have been developed 
primarily lor use with the Routing Inlormation Protocol 
as disclosed by C.L Hedrik. cited above, but are usable 
with the other distance-vector routing algorithms as well, to 
IP multicast algorithms (see, e.g. S.E. Deering and D. 
R. Cheriton, cited above; S.E. Deering: "Host Exten- 
sions for IP Multicasting'. RFC 1112, NIC. August 1988; 
L Hughes and P. Thomlinson; "A Multicast Internetwork 
Routing Algorithm", Proceedings of the IFIP WG 6.4 
Conference on High Speed Networking, 18-22 March 
1991, Berlin, pp. 183-200: D. Waitzman, C. Partridge, 
and S.E. Deering: "Distance Vector Multicast Protocol", 
RFC 1075, NIC, November 1988) are all variants of the 
Reverse Path Broadcasting algorithm described by Y. K. 20 
Dalai and R.M. Metcalfe in "Reverse Path Forwarding 
of Broadcast Packets', Communications of the ACM, 
Vol. 21, No. 12, pp. 1040-1048, ACM, December 1978. 
This algorithm is similar to the LAN multicast algorithm 
in that a spanning tree is used to distribute the multicast 2S 
packets, however it contains additional features to solve 
some of the problems associated with LAN multicasting. 
In brief, the algorithm works as follows (see S.E. Deering 
and D.R. Cheriton, cited above, for a more detailed de- 
scription): 30 

1 . Multicast packets are initially broadcast to all sub- 
networks in the internetwork. Packets are broad- 
cast on a least-cost spanning tree. When a router 
receives a multicast packet from some source "S\ 35 
it knows that it is on the spanning tree for mufticasts 
originating from S if its routing tables indicate that it 
can reach node S with a lower cost than all other 
routers attached to a given subnetwork (this infor- 
mation is available in the normal IP routing tables). 40 
If so; that router forwards the multicast packets on 
the subnetwork in question. It was shown by S.E. 
Deering and D.R. Cheriton, cited above, that this 
algorithm results in the multicast packet being dis- 
tributed to each subnetwork in the internetwork with 4S 
minimum cost. 

An obvious improvement of this scheme com- 
pared to the LAN multicasting schemes is that while 
here the multicast spanning tree is fixed for a given 
source, it is not the same for all sources. Thus mul- so 
ticast traffic is distributed over many different paths 
* in the network. 

2. In order to avoid broadcasting multicast packets 
to subnetworks that do not have members in the ss 
specified group, a scheme is used whereby routers 
that receive a multicast for a particular group that 
do not lie on a branch of the multicast tree that leads 



to any members of that group discard the multicast 
(there is obviously no need to forward it) and report 
to the predecessor in the multicast tree that this 
branch of the tree may be pruned. This process be- 
gins with routers attached to "leaf subnetworks" 
(subnetworks that are at the end of their respective 
branches on the tree), and works its way up the 
branch as far as possible to restrict the distribution 
of multicast traffic to where it is required. 

[0017] The IP multicast schemes have the following 
drawbacks: 

Initially, multicasts from a given source to a given 
group must be broadcast to the entire internet until 
the multicast tree for that source-destination pair is 
pruned. 

- The scheme requires that information used for 
pruning the multicast trees be discarded after some 
time so that new members that join the network on 
a previously pruned tree branch will eventually start 
receiving the multicasts. Thus, multicasts trees are 
continuously rebuilt and repruned, creating consid- 
erable overhead on the network links and process- 
ing nodes. 

- Multicast trees exist for each source-multicast 
group pair. That is, a separate logical multicast tree 
exists for each different source that multicasts to a 
given group. Thus routing nodes may have to main- 
tain an extremely large database for pruned multi- 
cast trees. 

[0018] For these reasons such protocols or algo- 
rithms seem unsuitable for use in the MPTN and similar 
architectures. A useful algorithm should be able to utilize 
the routing capabilities of gateways which have no mul- 
ticast intelligence. 

[0019] In some more detaiL the following goals or ob- 
jects ol the invention can be identfied as requirements 
for providing multicast service: 

1 . Multicast packets must not be broadcast to all 
subnetworks, and in fact should be restricted to be- 
ing sent only to subnetworks that have a multicast 
group member. 

2. Each multicast packet must be delivered exactly 
once to each destination subnetwork (i.e. duplicate 
multicast packets must not be created). 

3. The protocols should not require any centralized 
elements. They should be completely distributed. 

4. The protocols should not require computation of 
a spanning tree from a centralized database. 

5. Routing decisions for multicast packets must be 
flexible. Distribution of all multicasts over a fixed 
spanning tree for example is not acceptable. 

6. The number of packets distributed must be min- 
imized. In particular, it is not acceptable to generate 
a separate unicast packet for each destination. 
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7. The cost of distributing the multicast packets 
must be minimized. Thus, a good path must be tak- 
en from the multicast source to each destination. 

Summary of the Invention 5 

[0020] In brief, the present invention achieves the 
above objects by a method and a system for multicast- 
ing a message from a sending station to a plurality of 
receiving stations within a conventional unicast mes- 10 
sage transmission network using existing protocols by, 
at least in certain nodes within the network, maintaining 
tables of subnetworks with multicast receiving stations 
or tables of multicast receiving stations and by including 
appropriate routing information in the header of multi- 
cast messages, as further defined in the claims. 
[0021] With this invention, a solution is presented that, 
when used in combination with distance-vector routing 
protocols such as the standard OSI IDRP routing proto- 
col, disclosed in ISO 'Information Technology - Tele- so 
communications and Information Exchange between 
Systems - Intermediate System to Intermediate System 
Intra-Domain Routing Protocol for Use in Conjunction 
with the Protocol for Providing the Connection", ISO/DIS 
10589, 1990, or any other similar protocol, such as 25 
those used in IP networks referenced above, supports 
multicasting in large internetworks. This solution is also 
usable with link-state routing protocols, such as OSPF 
developed for IP networks (described by J. Moy in 
"OSPF Version 2", RFC 1247. NIC, July 1991) and the so 
OSI IS-IS protocol (described in ISO/DIS 10589, cited 
above) and are thus applicable to a wide range of inter- 
networking environments. Within the invention, three 
new types of protocols are presented: 

35 

1 . for the distribution of routing information based 
on network topology and the location of multicast 
group members, and for the creation of routing ta- 
bles using this information; 

2. for efficiently forwarding multicast packets to all 40 
members of a multicast group given the routing in- 
formation from the first step; and 

3. for enabling the multicast protocols to be used in 
the MPTN environment. 

45 

[0022] Details and examples of the invention will be 
described in the following in connection with the draw- 
ings. 

The Drawings so 
[0023] 

Fig. 1 a mufti-protocol transport network (MPTN) 

comprised of three subnetworks (already dis- ss 
cussed with the prior art above); 

Fig. 2 an example for another MPTN (also already 
discussed above); 



Fig. 3 an example of the information learned by 
gateways from attached subnetworks; 

Fig. 4 a detail in a subnetwork, namely all nodes with 
a common address prefix in such a subnet- 
work; 

Figs. 2 and 3 show essentially the same ar- 
rangement, the reference numbers are cho- 
sen such that the last digit of each number 
identifies the same part in each figure, i.e. "21 " 
in Fig. 2 is the same part as "31" in Fig. 3; 

Fig. 5 various nodes with a given address prefix in 
different subnetworks; 

Fig. 6 the so-called MPTN split net ID support. 

Detailed Description 

[0024] The following section is divided into four parts. 
The first part, entitled 'Routing Information", describes 
the routing information that is distributed and the tables 
that are created for routing multicast packets. The sec- 
ond part, entitled "Multicast Packet Forwarding", de- 
scribes the procedures for using the created tables to 
route multicast packets. Then, in the third part, entitled 
■Multicast with Reduced Routing Information", a de- 
scription is given of how the amount of routing informa- 
tion required for the multicasting protocols can be re- 
duced. Finally, in part four, entitled "MPTN Use of Mul- 
ticast", an example is given of how MPTN uses the pro- 
tocols described in this invention. 

Routing Information 

[0025] A brief description of the Inter-Domain Routing 
Protocol (IDRP) protocol is provided so that the inven- 
tion may be better understood. Further details can be 
found in ISO/DIS 10589, referred to above. 
[0026] IDRP distributes routing information between 
gateways in so-called Update PDUs, i.e. Update Proto- 
col Data Units. Update PDUs contain the following fields 
that are relevant to the invention. 

1. Reachability Information: this field specifies the 
resources that can be reached along the path spec- 
ified in this Update PDU. It can be the address of a 
specific end system, or it can be the prefix common 
to the addresses used by a set of end systems. All 
systems whose address contains a given prefix re- 
side in the same subnetwork, and therefore this pre- 
fix uniquely identifies this subnetwork. A type field 
is defined in the reachability information which indi- 
cates that the reachability information is an address 
prefix (type = 0). Thus, different types of reachability 
information could be distributed in Update PDUs by 
defining a new type code. 

2. Quality of service: this specifies properties like 
cost, delay, and security implications of using the 
routing information in this update PDU. 

3. Path: the routing information that specifies how 
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to reach the end syst ems identified by the prefix 
(es) in the reachability information. 

[0027] Based on received Update PDUs, gateways 
build routing tables, called Forwarding Information Bas- 
es (FIBs) in IDRR For each destination (a destination is 
identified by a prefix received in an Update PDU, and 
may thus be a single node or a set of nodes), the next 
gateway on the path to that destination is stored (this is 
determined Irom the path field in the update PDU). Ex- 
actly one path lor each prefix is stored for each unique 
set of quality of service parameters. This path is the one 
that can best provide the specified quality of service. 
[0028] In the invention, a new type of reachability in- 
formation is defined, called a group identifier (groupid). 
A groupid is used to address a group of end systems 
that are to receive a particular set of multicasts. The 
groupid, which is chosen from the normal subnetwork 
address space, is therefore included as the destination 
address of a multicast packet so that the proper group 
of end systems is identified. The end systems ad- 
dressed by a particular groupid are not necessarily lo- 
cated in a common subnetwork. Selecting groupids from 
the standard address space guarantees that they rep- 
resent valid reachability information even for gateways 
which do not implement the multicast extensions de- 
scribed below. 

[0029] To support unicast inter-domain routing, sub- 
networks report the address prefix(es) shared by its 
nodes to gateways. These prefixes are used to create 
the Update PDUs as described above. In the invention, 
subnetworks also report all groupids reachable in that 
subnetwork. 

[0030] An example is illustrated in Fig. 3. In that figure, 
the subnetworks with prefixes X (32) and 2 (34) also 
have end systems in group G. They therefore report 
both the prefix and the groupid to the local gateways C 
(39) and E (37). Subnetworks W (31 ) and Y (33) do not 
have any groupids to report, so they report only their 
prefixes. Note that a given subnetwork may report mul- 
tiple groupids and prefixes (not illustrated). 
[0031] IDRP Update PDUs are constructed as fol- 
lows. Update PDUs not containing groupids are con- 
structed as specified in ISO/DIS CD 10747, mentioned 
above. Update PDUs used to advertise reachability to 
groupids must contain the following information: 

An address prefix of the subnetwork, and 
one or more groupids for that subnetwork. 

[0032] The reachability information in an Update PDU 
containing groupids consists of only the groupids and 
(one of) the address prefix(es) unique to the end sys- 
tems in the subnetwork reporting the groupids, so that 
all gateways will be able to build an association between 
the subnetwork prefix and the groupids reachable in that 
subnetwork. 

[0033] The Update PDU constructed in this manner is 



delivered with the reachability information field un- 
changed to all gateways according to the existing IDRP 
protocols. Note that this Update PDU construction is al- 
lowed by the I DRP standard, and that no other changes 
5 to the Update PDU construction or distribution are re- 
quired. 

[0034] In the example shown in Fig. 3, gateway C (39) 
would create an Update PDU with the following reach- 
ability information: prefix = X, groupid = G. Similarly, 
gateway E (37) would create an Update PDU with prefix 
= Z and groupid = G. Both of these Update PDUs would 
be distributed to all other gateways according to the ID- 
RP protocol to allow all of them to learn the association 
between group G and subnetworks X and 2. 
[0035] As reachability information changes (e.g., the 
prefix changes, or groupids are added or deleted), the 
changes are reported to the local gateways which use 
the normal IDRP routing protocols to update all MPTN 
gateways with the new information. 
[0036] Construction of Update PDUs as specified 
above allows gateways to build an additional routing ta- 
ble which will be referred to as the Multicast Routing Ta- 
ble or MURT. The MURT contains for each groupid the 
list of prefixes for subnetworks containing members of 
that group, as learned from Update PDUs containing 
groupids. How the MURT is used for routing is explained 
in the next section. 

[0037] In the system of Fig. 3, following the distribu- 
tion of the Update PDUs as described above, each gale- 
way would have a MURT entry for groupid G, identifying 
X and 2 as the prefixes of subnetworks in which group 
members are located. 

[0038] The remaining IDRP routing tables (e.g., the 
FIB as described above) are constructed according to 
existing IDRP specifications. In particular the path infor- 
mation associated with all reachability information (in- 
cluding groupids) is stored in the FIB. 
[0039] Thus far in this section, the procedure for con- 
structing a MURT using the OSI IDRP routing protocol 
has been described. This same procedure can be used 
with any distance-vector routing protocol, as e.g. de- 
scribed in the following references: C.L Hedrick, "Rout- 
ing Information Protocol", RFC 1058, NIC, June 1988; 
R.M. Hinden and A Sheltzer, cited above; K. Lougheed 
and Y. Rekhter : cited above; D.L. Mills, cited above. In 
all such protocols, Update PDUs are distributed to ad- 
vertise reachability to a given address or address prefix. 
By associating groupids with each address prefix, a 
MURT can be constructed as described above. 
[0040] A MURT can also be constructed using link- 
state routing protocols such as those described in ISO/ 
DIS 10589, 1990 or in J. Moy, cited above. In those pro- 
tocols, each gateway distributes reachability informa- 
tion in link-state PDUs : which provide information on the 
state of each link adjacent to that gateway, as well as 
all address prefixes directly reachable from that gate- 
way. These link state PDUs are forwarded unmodified 
to all other gateways in the system. Therefore, by also 
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including a list of groupids in the link state PDUs, a 
MURT can be constructed associating the group with a 
list of address prefixes of subnetworks in which group 
members reside. Both distance-vector and link-state 
routing protocols create an FIB which is essentially s 
equivalent to that created by IDRP. Due to this, the mul- 
ticast forwarding algorithm described in the next section 
is also applicable to these environments. 



Multicast Packet Forwarding 



10 



[0041] Conceptually, once the MURT is constructed 
as described in the previous section, routing of multicast 
packets is very simple. The MURT allows the subnet- 
works in which members of the multicast group are lo- 
cated to be identified. Furthermore, the IDRP FIB can 
be used to route packets to each of these subnetworks. 
A copy of each multicast packet could simply be routed 
to each of these subnetworks. However, due to the 
MPTN requirements specified in the section entitled 20 
Summary of the Invention, above, regarding restrictions 
on the number of distributed packets, the methods and 
algorithms specified in this section are an essential part 
of this invention. 

[0042] The invention also defines a Multicast Span- 2S 
ning-Tree Algorithm (MSTA) for routing multicast pack- 
ets in an MPTN. The MSTA is also usable in other net- 
works that provide routing information similar to that 
specified in the previous section. 

[0043] To assist the reader in understanding, MSTA so 
is presented in an example before the detailed algo- 
rithms are given. 

[0044] The topology of the network used in this exam- 
ple is illustrated in Fig, 3. Using the protocols of the pre- 
vious section, the following routing tables are construct- 35 
ed at the respective MPTN gateways: 
At gateway A (35) 

FIB (prefix: next hop on shortest path) 

address prefix W: addresses with this 
prefix are located in the local subnet (31 ) 40 

X: the next gateway on the path to the 
subnet containing addresses with this prefix is Gateway 
B. 

Y: gateway B 

Z: gateway B 4S 
G: gateway B 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated 
with this groupid are X,Z 

At gateway B (36) so 
FIB (prefix: next hop on shortest path) 

W: the next gateway on the path 
to the subnet containing addresses with this prefix is 
Gateway A. 

X; gateway C ss 
Y: gateway D 
Z: gateway E 
G: gateway E 



MURT (groupid: associated prefixes) 

groupid G: the prefixes associated 
with this groupid are X,Z 
At gateway C (39) 

FIB (prefix: next hop on shortest path) 

address prefix X: addresses with this 
prefix are located in the local subnet (32) 

W: the next gateway on the path to the 
subnet containing addresses with this prefix is Gateway 

Y; gateway D 
Z: gateway B 
G: local subnet (32) 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated 
with this groupid are X,Z 
At gateway D (38) 

FIB (prefix: next hop on shortest path) 

address prefix Y: addresses with this 
prefix are located in the local subnet (33) 

W: the next gateway on the path to tie 
subnet containing addresses with this prefix is Gateway 

X: gateway C 
Z: gateway B 
G: gateway C 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated 
with this groupid are X,Z 
At gateway E (37) 

FIB (prefix: next hop on shortest path) 

address prefix Z: addresses with this 
prefix are located in the local subnet (34) 

W: the next gateway on the path to the 
subnet containing addresses with this prefix is Gateway 

X: gateway B 
Y: gateway B 
G: local subnet (34) 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated 
with this groupid are X,Z 

[0045] The basic layout is shown in Fig. 3. In this ex- 
ample, G is the groupid of a multicast group which has 
members in subnetworks X (32) and Z (34). A source 
node in subnetwork W (31 ) sends a multicast to groupid 

G. 

[0046] MPTN gateway A (35) receives the multicast 
packet addressed to groupid G from subnetwork W (31 ). 
Its MURT entry indicates that the multicast is to be sent 
to the subnetworks with prefixes X (32) and Z (34). From 
its FIB, gateway A (35) determines that the next hop for 
both X and Z is gateway B (36). It therefore sends an 
MPTN multicast packet to gateway B (36) with the fol- 
lowing fields: 

destination = G 

target subnetworks = X, Z 
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data as specified in the original multicast packet 

[0047] Note that the target subnetworks field specifies 
all unique destination subnetworks for this multicast on 
a given path. Since both subnetworks X (32) and Z (34) s 
are reached through gateway B (36), only a single pack- 
et is sent from gateway A (35) to gateway B (36) to ac- 
complish the multicast. 

[0048] Gateway B (36) receives the multicast packet 
specified above. Since the target subnetworks are spec- to 
ified. it does not need to make use of the MURT. Note 
that this implies that only gateways that are attached to 
possible sources of multicast traffic need to maintain a 
MURT. All other gateways do not need to create this ta- 
ble. Gateway B uses its FIB to determine that the next is 
hop for subnetwork X is gateway C (39) and for subnet- 
work Z (34) gateway E (37). It therefore sends an MPTN 
multicast packet to gateway C with the following fields: 



destination = G 20 
target subnetworks = X 

data as specified in the original multicast packet 

[0049] Note that the target subnetworks field only in- 
cludes those subnetworks on this path. Subnetwork Z ?s 
(34) is reached via a different path and is therefore not 
included in the multicast to gateway C (39). 
[0050] Similarly, gateway B (36) sends an MPTN mul- 
ticast packet to gateway E (37) with the following fields: 

30 

destination = G 
target subnetworks = Z 

data as specified in the original multicast packet 

[0051] Gateway C (39) receives the multicast des- 35 
tined for subnetwork X (32) to which it is attached. It 
therefore multicasts the packet to groupid G in subnet- 
work X. Similarly, gateway E (37) multicasts the packet 
in subnetwork Z (34) to all members of groupid G. Thus 
the multicast is delivered to all members of groupid G. <o 
The algorithms above meet all MPTN requirements for 
efficient multicast: 

1. The packet was only multicast in subnetworks 
that have a multicast group member (e.g., X and Z t « 
but not Y). The MURT identifies the destination sub- 
networks. 

2. Each multicast packet was delivered exactly 
once to each subnetwork. The target subnetworks 
field of the MPTN multicast is used to ensure that so 
each subnetwork receives exactly one copy of the 
multicast. 

3. There are no centralized elements. The creation 
of the MURT, and the routing of multicast packets 

is completely distributed. ss 

4. The algorithms do not require computation of a 
spanning tree from a topology database. 

5. The multicast routing has all the flexibility of nor- 



mal MPTN routing. As shown in the example, the 
normal IDRP FIBs are used to route multicast pack- 
ets. This implies that different routes may be used 
for different multicast packets due to different qual- 
ity of service requirements and/or changing network 
conditions (topology or load). 

6. The number of packets distributed is minimized. 
A multicast packet to several destinations (e.g., X 
and Z) is only sent as separate packets when the 
best routes to the different destinations are not the 
same. In the example, only a single packet was sent 
from gateway A to gateway B, but gateway B sent 
individual packets to gateways C and E. 

7. The multicast packets are sent on the best route 
to each destination according to the IDRP FIB. A 
unicast packet to one of the given destinations 
would follow the same path as the multicast packet 
to that destination. 

[0052] It is also important that only a single MURT en- 
try is created per multicast group. The multicast algo- 
rithms for the Internet Protocol described in the Prior Art 
section of this disclosure require nodes to create mufti- 
cast tables with entries for each source-group pair (thus 
the number of entries is multiplied by the total number 
of sources compared to the MPTN scheme). 
[0053] Having given the above informal description of 
the MPTN multicast packet forwarding algorithm the 
procedures for multicasting are now specified in detail. 
One procedure is specified for the MPTN gateway that 
initially receives the multicast packet frum a subnetwork 
(List A), and one for intermediate MPTN gateways that 
forward multicasts received from other gateways (List 
B). 

List A - Procedure: lnitiate_MPTN_Multicast 

This procedure is used by an MPTN gateway 
that receives a multicast packet from a subnetwork. 

Input: The subnetwork multicast packet which 
specifies a destination groupid, quality 
of service, and the data to be multicast. 

Output: MPTN multicast packets to the next 
gateways on the path to the target, or a 
multicast directly to target subnetworks 
that are directly attached to the gateway 

Using the specified groupid as a key into the 
MURT obtain the list of prefixes for subnetworks 
containing members of the group. 

For each prefix in the list 

Use the prefix and the specified quality of serv- 
ice as a key into the IDRP FIB to determine the 
next hop gateway on the path to that subnet- 
work. 

Add this prefix to a list for the particular next 
hop. 
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For each next hop list created above 

Set target_subnetworks to the list of prefixes 
associated with that next hop. 
Send the MPTN multicast including the grou- 
pid, larget_subnelworks, quality of service, and 
data to that next hop. 

Note that in some cases the target subnetwork 
is directly attached to this gateway and that the mul- 
ticast is forwarded directly to that subnetwork in 
those cases. 

List B - Procedure: Forward_MPTN_Multicast 

This procedure is used by an MPTN gateway 
to forward a multicast packet received from another 
MPTN gateway. 

Input: The MPTN multicast including the grou- 
pid, target.subnetworks, quality of serv- 
ice, and data as created in procedure In- 
itiate MPTN_Mutticast. 

Output: MPTN multicast packets to the next 
gateways on the path to the target, or a 
multicast directly to target subnetworks 
that are directly attached to the gateway. 

For each prefix in the received 
target_subnetworks list 

Use the prefix and the specified quality of serv- 
ice as a key into the IDRP FIB to determine the 
next hop gateway on the path to that subnet- 
work. 

Add this prefix to a list for the particular next 
hop. 



For each next hop list created above 

Set targeLsubnetworks to the list of prefixes 
associated with that next hop. 
Send the MPTN multicast including the grou- 
pid, target_subnetworks, quality of service, and 
data to that next hop. 

Note that in some cases the target subnetwork 
is directly attached to this gateway and that the mul- 
ticast is forwarded directly to that subnetwork in 
those cases. 

Multicast with Reduced Routing Information 

[0054] In the multicasting scheme described in the 
previous sections, a MURT entry for a group is required 
at every gateway that is attached to a potential source 
of multicast traffic to that group. In large MPTNs with 
many groups, this may be undesirable. Therefore in this 
section, an alternative scheme is described in which 



MURT entries for a particular multicast group need only 
be maintained at gateways attached to subnetworks 
with members in that group (other gateways may option- 
ally maintain these MURT entries). This scheme can po- 

s tentially reduce the amount of storage required to sup- 
port multicasting at the expense of optimal routing, as 
will be shown. The scheme described in this section is 
an integral part of this invention, and can be used in 
combination with, or in place of the previous scheme 

"> [0055] With this scheme, subnetworks report grou- 
pids and address prefixes to adjacent gateways as was 
described in the section entitled Routing Information. 
These gateways must create MURT entries for the spec- 
ified groupids. They must also create IDRP update 

« PDUs as described in the addressed section. However, 
gateways not attached to a subnetwork containing 
members of a particular groupid are not forced to main- 
tain MURT entries for that groupid. 
[0056] Forwarding of packets addressed to a groupid 
& is done as follows: 



If a packet to be forwarded has the target subnet- 
works field set by a previous MPTN gateway, it is 
forwarded according the the algorithm in List B. This 
can be done by all gateways since a MURT is not 
required for this algorithm (the destination prefixes 
are specified in the target subnetworks field). 
If a packet to be forwarded does not have the target 
subnetworks field set, and the destination address 
is a groupid for which a MURT entry is maintained 
at this gateway, the procedure for initiating an 
MPTN multicast in List A is followed. 
If a packet to be forwarded does not have the target 
subnetworks field set, and no MURT entry exists for 
the destination address, the packet is forwarded 
point-to-point based on the IDRP FIB entry for that 
address. 



25 



30 



35 



[0057] If only the gateways attached to the subnet- 
<o works with members of a group have a MURT entry for 
that groupid, the packet will be routed point-to-point to 
one of those gateways, which will then cause it to be 
multicast to the remainder of the gateways. 
[0058] The above algorithm for routing with reduced 
« information is illustrated with an example, again refer- 
ring to the network depicted in Fig. 3. Using the protocols 
specified in this section, the following routing tables are 
constructed at the respective MPTN gateways: 
At gateway A (35) 
50 F,B (prefix: next hop on shortest path) 

address prefix W: addresses with this 
prefix are located in the local subnet (31) 

X: the next gateway on the path to the 
subnet containing addresses with this prefix is Gateway 

£5 B. 

Y: gateway B 
Z: gateway B 
G: gateway B 
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At gateway B (36) 

FIB (prefix: next hop on shortest path) 

W: the next gateway on the path to the 
subnet containing addresses with this prefix is Gateway 
A. 5 
X: gateway C 
Y: gateway D 
Z: gateway E 
G: gatewav E 

At gateway C (39) 70 
FIB (prefix: next hop on shortest path) 

address prefix X: addresses with this 
prefix are located in the local subnet (32) 

W: the next gateway on the path to the 
subnet containing addresses with this prefix is Gateway J$ 
B. 

Y: gateway D 
Z: gateway B 
G: local subnet (32) 
MURT (groupid: associated prefixes) 20 
groupid G: the prefixes associated 
with this groupid are X,Z 
At gateway D (38) 

FIB (prefix: next hop on shortest path) 

address prefix Y: addresses with this 2s 
prefix are located in the local subnet (33) 

W: the next gateway on the path to the 
subnet containing addresses with this prefix is Gateway 
B. 

X gateway C 30 

Z: gateway B 

G: gateway C 
At gateway E (37) 

FIB (prefix: next hop on shortest path) 

address prefix Z: addresses with this 3$ 
prefix are located in the local subnet (34) 

W: the next gateway on the path to the 
subnet containing addresses with this prefix is Gateway 
B. 

X: gateway B 40 

Y: gateway B 

G: local subnet (34) 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated 
with this groupid are X,Z 4$ 
[0059] In this example, "G" is the groupid of a multi- 
cast group which has members in subnetworks X (32) 
and Z (34), and it is assumed that only gateways C (39) 
and E (37) maintain MURT entries for groupid G. Hence, 
all other gateways treat G like a unicast address (i.e., so 
according to the existing IDRP procedures), and there- 
fore maintain a single entry for G in their FIBs. The fact 
that multiple gateways advertise a path to G (gateways 
C and E in the example) is not a problem, since IDRP 
allows for this. However, gateways only store routing in- ss 
formation (in the FIB) for the best path for a given prefix. 
For example, gateway B (36) has a FIB entry of gateway 
E (37) associated with G rather than gateway C (39). 



This could have been reversed, but in any event only 
one of the paths is stored in the FIB. 
[0060] MPTN gateway A (35) receives a multicast 
packet addressed to G from subnetwork W (31 ). It does 
not have a MURT entry for G, so it routes the packet 
based on the FIB entry for G (to gateway B) with the 
following fields: 

destination = G 

target subnetworks = not set 

data as specified in the original multicast packet 

[0061] Note that the target subnetworks field is not set 
since the MURT entry for G is not available. 
[0062] Gateway B (36) receives the packet, and since 
it also does not have a MURT entry for G, routes the 
packet based on its FIB to gateway E (37) with the fol- 
lowing fields: 

destination = G 

target subnetworks = not set 

data as specified in the original multicast packet 

[0063] Gateway E (37) is attached to subnetwork Z 
which has members in group G, and therefore it has a 
MURT entry for G. The MURT indicates that the packet 
is to be multicast in subnetworks with prefixes X and Z. 
Since subnetwork Z (34) is attached, it multicasts the 
packet into that subnetwork. Since the FIB entry for sub- 
network X (32) is gateway B (36), an MPTN multicast 
packet is sent to gateway B with the following fields: 

destination = G 
target subnetworks = X 

data as specified in the original multicast packet 

[0064] Since the target subnetworks fields is now set 
gateway B (36) forwards the packet based on that field 
(contrast the routing decision made here to that made 
at gateway B above). Thus, since the FIB entry for sub- 
network X (32) is gateway C (39), it forwards the MPTN 
multicast packet to gateway C with the following fields: 

destination = G 
target subnetworks = X 

data as specified in the original multicast packet 

[0065] Finally, gateway C (39) multicasts the packet 
to groupid G in subnetwork X (32) to which it is attached. 
[0066] Note that in this example the packet was rout- 
ed through gateway B (36) twice; once with the target 
subnetworks field not set, and once with it set. Thus, the 
savings in storage for not maintaining the MURT entries 
at gateways A. B, and D (35, 36, and 38) come at the 
expense of suboptimal routing behavior for multicast 
packets. 
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MPTN Use of Multicast 

[0067] As noted previously, MPTN relies on multicast- 
ing to support multicasts by applications using MPTN, 
and to support MPTN control algorithms. These prob- 
lems and the manner in which they are solved are de- 
scribed in this section. 

[0068] Existing routing protocols require that all nodes 
whose addresses have a common prefix be located in 
a single subnetwork. In that way, the prefix uniquely 
identifies the subnetwork, and operations involving 
nodes with the given prefix can be entirely performed 
within that subnetwork. This is illustrated in Fig. 4. 
[0069] MPTN allows nodes in different subnetwork to 
have the same address prefix. Thus, such a prefix does 
not uniquely identify a particular subnetwork, and oper- 
ations involving nodes with this prefix may have to be 
distributed over multiple subnetworks. This is illustrated 
in Fig. 5. This is referred to as a "split netid'. since "netid" 
is a synonym for address prefix, and "split" implies that 
the nodes with the given netid are split up among differ- 
ent subnetworks. The subnetworks containing nodes in 
the split netid are called "islands" of that split netid. Thus s 
Fig. 5 illustrates a split netid with 3 islands. Support of 
such split netids has implications on the following MPTN 
operations: 

1 . Packets multicast by MPTN users to nodes in a 
split netid must be delivered to all subnetworks con- 
taining such nodes. 

2. In order to route connectbns and unicast data- 
grams to a node in a split netid, MPTN gateways 
must first determine in which island of the split netid 
the destination is located. 

3. Subnetwork protocols that ensure that all ad- 
dresses in use in that subnetwork are unique must 
be extended to all islands of a split netid, since 
nodes with the same address could exist there due 
to the use of the same address prefix. 

[0070] In order to support split netids, the multicast 
protocols described in this invention are used. In partic- 
ular the address prefix common to the nodes in the split 
netid is treated like a groupid, and this groupid is regis- 
tered with all MPTN gateways adjacent to all islands of 
the split netid. Thus, the groupid identifies the group of 
all islands of the split netid. User datagrams and con- 
nection requests will be received that specify a destina- 
tion address that begins with the split netid prefix (i.e., 
the groupid), since users will want to communicate with 
resources in that split netid. MPTN control packets will 
be addressed to the groupid in order to communicate 
with one gateway attached to each island of the split 
netid, as explained below. As with other groups, each 
group member (i.e., each island) also requires a unique 
prefix that will be associated with the groupid in the 
MURT. This is obtained as follows. 
[0071] Each gateway attached to a split netid has an 



address in that subnetwork which is globally unique (this 
global uniqueness is guaranteed by the subnetwork pro- 
tocols). If this gateway is the only gateway attached to 
a particular island ol the split netid, it may use its own 

s address in that subnetwork as the unique prefix for the 
island. Since all routing protocols in the class relevant 
to this invention (e.g., IDRR IP : OSPF : OSI IS-IS) require 
that gateways communicate to exchange routing infor- 
mation, gateways will automatically have contact with 

70 all other gateways attached to the same island of the 
split netid (i.e., all of those gateways with which it ex- 
changes routing information through that subnetwork). 
Thus, gateways are aware when multiple gateways are 
attached to the same island of a split netid, and also 

is when gateways are added or removed from the set at- 
tached to a split netid island. 

[0072] The method for selecting a unique prefix to as- 
sociate with an island of a split netid is as follows: 

so 1 . When a gateway is initially activated, it assumes 
that its own address will be used as the unique pre- 
fix for the split netid island to which it is attached. 
2. Whenever a gateway becomes aware of the ex- 
istence of other gateways attached to the same is- 

25 land (which it must in order to implement the exist- 
ing routing protocols): it examines the addresses of 
all such gateways and uses the smallest such ad- 
dress (which might be its own) as the unique prefix 
for the split netid. Since all gateways will execute 

30 this algorithm, they will converge to using the same 
address as the prefix to uniquely identify this island. 

[0073] This step must be repeated whenever a gate- 
way is added or dropped from the set of gateways at- 

35 tached to the local split netid island. 

[0074] This method provides valid unique prefixes for 
split netid islands in the case where two or more disjoint 
islands are joined into one island, or when a single island 
is dynamically split into several islands. The algorithm 

<o is completely distributed and is guaranteed to result in 
a correct assignment of unique prefixes to gateways at- 
tached to split netid islands. 

[007S] The unique address prefixes associated with 
a split netid is called a 'derived netid". This is illustrated 
4$ in Fig. 6. 

[0076] In that Fig. 6, we see that nodes with address 
prefix X are located in two different subnetworks. There- 
fore X, a split netid, is registered as a groupid with the 
MPTN gateways attached to those subnetworks. Gate- 
so way G (62) is the only gateway attached to the top island 
of split netid X. It therefore uses its local address X.7 as 
the unique prefix to be associated with groupid X. Gate- 
ways H (63) and I (64) are attached to the lower island 
of the split netid. Since gateway H's address is less that 
ss gateway I's (X.8 is less than X.9), they both use X.B as 
the unique prefix to be associated with groupid X. Using 
the protocols of this invention, Gateway F (61 ) builds the 
illustrated FIB and MURT table entries associated with 



11 



21 



EP 0 598 969 B1 



22 



the address prefix X. 

[0077] Using the multicast protocols from the previous 
sections, and the procedure for mapping split netids to 
groupids and derived netids in this section, it is possible 
to support split netids in MPTN. 5 
[0078] If an MPTN user's packet is to be multicast to 
all nodes with prefix X, the packet can be distributed to 
all islands of the split netid using the procedures of the 
previous sections since X is an entry in the MURT. In 
the same way, flows which are part of subnetwork name io 
management protocols can be multicast to all parts of a 
spirt netid. 

[0079] If a connection or unicast datagram is to be 
sent to a node with prefix X (say X.3 in the example in 
Fig. 6), an additional protocol is required, which forms is 
another part of this invention. An MPTN gateway that is 
required to route a unicast packet or connection based 
on an address prefix which appears in the MURT uses 
this procedure. 

20 

1 . Using the multicast method described in this in- 
vention, a LOCATE request is distributed to one 
MPTN gateway attached to each island of the split 
netid. A parameter of the LOCATE is the specific 
address which is the target of the original unicast 2S 
packet (i.e., the resource that is to be located). Thus 

in the example, gateway F (61) multicasts a LO- 
CATE to gateways G (62) and H (63) to determine 
the location of the resource X.3. 

2. Each gateway that receives such a LOCATE re- 30 
quest searches the attached subnetwork (using the 
native protocols of that subnetwork, or MPTN pro- 
tocols) to determine if the target resource is actually 
located in that island of the split netid. In the exam- 
ple, gateway G (62) discovers that X.3 is located in 3S 
the attached subnetwork, while gateway H (63) is 

not able to locate X.3. 

3. All gateways that received the LOCATE return a 
response to the MPTN gateway that initiated the 
search that includes the unique prefix of the re- 40 
sponder, and a flag which indicates if the resource 
was found or not. In the example, gateway G (62) 
returns a response to gateway F (61) that includes 

its unique address prefix X.7, and a flag that indi- 
cates that the resource was found. Gateway H (63) <s 
returns a result indicating that the resource was not 
found. 

4. As soon as a positive response to the search is 
obtained, gateway F (61) is able to route the unicast 
message or connection to the proper destination, so 
The header of that request must indicate to which 
gateway the request is being routed (X.7 in the ex- 
ample) so that all gateways can forward the re- 
quest. The header must further include the address 

to which the request is destined (X.3) so that the ss 
final gateway will be able to route it through the sub- 
network containing the destination. 



[0080] It is important for gateways that cannot locate 
a particular resource to send a negative response to a 
LOCATE request. Otherwise, in the case where the tar- 
get resource does not exist (e.g., a user attempts to 
send a message to X.5 which does not exist), the gate- 
way that needs to route the request would watt forever 
for a response. Instead, if a negative response is re- 
ceived from each gateway it knows that the resource in 
question is unreachable and it can therefore reject the 
original request. 

[0081] This terminates the description of the preferred 
embodiments. Of course, numerous variations of the 
given examples are possible, still within the scope of the 
invention as claimed. 



Claims 

1. A method for multicasting a message from a send- 
ing station to a plurality of receiving stations within 
a conventional unicast message transmission net- 
work using existing protocols, said network consist- 
ing of a plurality ol subnetworks including nodes 
(gateways A...E) connecting and acting as entry 
ports to, said subnetworks, 

wherein one or more of the gateways (35... 39) 
connecting the subnetworks (31. ..34) maintain 
a routing table (MURT) to multicast receiving 
stations, 

and a header included in each multicast mes- 
sage transmitted includes information (groupid) 
defining a group of said multicast receiving sta- 
tions. 

2. The method of claim 1, wherein the routing table 
(MURT) of a gateway contains, particularly in addi- 
tion to conventional routing information, one or 
more group identifier(s) (groupid) defining at least . 
one multicast receiving station, preferably a group 
of multicast receiving stations, and a prefix identify- 
ing the subnetwork(s) in which the multicast receiv- 
ing station(s) is/are located. 

3. The method of claim 2, wherein the receiving station 
(s) defined by the group identifier (groupid) is/are 
located in different subnetworks. 

4. The method of one or more of the preceding claims, 
wherein the routing tables (MURT) maintained in a 
particular gateway includes information of only 
those multicast receiving stations that can be 
reached via said gateway. 

5. The method of one or more of the preceding claims, 
wherein only those gateways which are connected 
to possible sources of multicast messages maintain 
a table (MURT) of the addressable multicast receiv- 
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ing stations. 

6. The method of one or more of the preceding claims, 
wherein the group identification (groupid) and/or the 
address prefixes are transmitted to the gateways to- s 
gether with the conventional routing information. 

7. A system for multicasting a message from a sending 
station to a plurality of receiving stations within a 
conventional unicast message transmission net- to 
work using existing protocols, said network consist- 
ing of a plurality of subnetworks connected by 
nodes (gateways A...E) : wherein 

one or more gateways (37...39) connecting is 
said subnetworks (31 ...34) include a routing ta- 
ble for multicast receiving stations. 

each multicast message to be transmitted car- 
ries a header that includes information defining 20 
a group of the multicast receiving stations, 

means are provided in each gateway for inter- 
preting, comparing and modifying the header of 
the multicast message. 2s 

8. The system of claim 7 , wherein the subnetworks are 
of different type and/or use different message trans- 
mission protocols. 



2. Verfahren von Anspruch 1 , wobei die Leitwegtabel- 
le (MURT) eines Gateways insbesondere zusatz- 
lich zur konventionllen Leitweginformation einen 
Oder mehrere Gruppenkennzeichner {Gruppen-ID}, 
die mindestens eine die Mehrfachsendung empfan- 
gende Station, vorzugsweise eine Gruppe von die 
Mehrfachsendung empfangenden Stationen defi- 
nieren, und einen Vorsazcode enthalt, der das/die 
Teilnetzwerk(e) kennzeichnet, in denen die die 
Mehrfachsendung empfangende(n) Station(en) an- 
geordnet ist/sind. 

3. Verfahren von Anspruch 2, wobei die Empfangssta- 
tion(en) : die durch den Gruppenkennzeichner 
(Gruppen-ID) definiert werden, in unterschiedlichen 
Teilnetzwerken angeordnet ist/sind. 

4. Verfahren nach einem Oder mehreren der vorher- 
gehenden AnsprOche, wobei die Leitwegtabellen 
(MURT), die in einem bestimmten Gateway verwal- 
tet werden, Information nur von denjenigen die 
Mehrfachsendung empfangenden Stationen ent- 
halten, die Ober den Gateway erreicht werden kon- 



9. The system of claim 8, wherein only a subset of the 
subnetworks is equipped to support multicasting. 



Patenlanspruche 



30 



3S 



1. Verfahren zum Mehrfachsenden einer Nachricht 
von einer Sendestation an eine Vielzahl von Em- 
fangsstationen innerhalb eines konventionellen 
Einfachsende-NachrichtenObertragungsnetz- *o 
werkes unter Verwendung vorhandener Protokolle, 
wobei das Netzwerk aus einer Vielzahl von Teilnetz- 
werken besteht, die Knoten (Netzkoppler, Gate- 
ways A...E) enthalten, welche die Teilnetzwerke 
verbinden und als Eingabeanschlusse dazu fungie- 4$ 
ren : 

wobei einer Oder mehrere der Gateways (35... 
39), welche die Teilnetzwerke (31 ...34) verbin- 
den, eine Leitwegtabelle (MURT) verwalten, so 
urn an Empfangsstationen mehrfach zu sen- 
den, 

und ein Kennsatz, der in jeder ubertragenen 
Mehrfachesendenachricht enthalten ist, Infor- ss 
mation (Gruppen-ID) enthalt, die eine Gruppe 
der die Mehrfachsendung empfangenden Sta- 
tionen definiert. 



Verfahren nach einem oder mehreren der vorher- 
gehenden AnsprOche, wobei nur diejenigen Gate- 
ways, die mit moglichen Quellen von Mehrfachsen- 
de-Nachrichten verbunden sind. eine Tabelle 
(MURT) der adressierbaren die Mehrfachsendung 
empfangenden Stationen verwalten. 

6. Verfahren nach einem oder mehreren der vorher- 
gehenden AnsprOche, wobei die Gruppenkenn- 
zeichnung (Gruppen-ID) und/oder die AdreGvor- 
satzcodes zusammen mit der konventionellen Leit- 
weginformation an die Gateways ubertragen wer- 
den. 

7. System zum Mehrfachsenden einer Nachricht von 
einer Sendestation an eine Vielzahl von Empfangs- 
stationen innerhalb eines konventionellen Ein- 
fachsende-NachrichtenObertragungsnetzwerkes 
unter Verwendung vorhandener Protokolle, wobei 
das Netzwerk aus einer Vielzahl von Teilnetzwer- 
ken besteht, die durch Knoten (Netzkoppler, Gate- 
ways A...E) verbunden sind, wobei 

ein oder mehrere Gateways (37... 39), wetche 
die Teilnetzwerke (31. ..34) verbinden, eine 
Leitwegtabelle fur Mehrfachsendung empfan- 
gende Stationen enthalten, 

jede Mehrfachsende-Nachricht, die ubertragen 
werden soli, einen Kennsatz tragt, der Informa- 
tion enthalt, die eine Gruppe der die Mehrfach- 
sendung empfangenden Stationen definiert, 
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in jedem Gateway Mittel zum Ubersetzen, Ver- 
gleichen und Modifizieren des Kennsatzes der 
Mehrfachsendenachricht bereitgesteltt war- 
den. 

System von Anspruch 7, wobei die Teilnetzwerke 
von unterschiedlicher Art sind und/oder unter- 
schiedliche NachrichtenObertragungsprotokolle 
benutzen. 

System von Anspruch 8, wobei nur eine Teitmenge 
der Teilnetzwerlce so ausgerustet ist, dafl sie Mehr- 
fachsendung unterstutzen. 



Revendications 

1. Un procede d'acheminement a destinations multi- 
ples d'un message, depuis un poste emetteura une 
plurality de postes recepteurs se trouvant dans un 
reseau de transmission de messages a une seule 
machine, classique, par utilisation de protocoles 
existants, ledit reseau etant constitue d'une plurali- 
ty de sous-reseaux comprenant des noeuds (pas- 
serelles A....E) assurant la liaison et agissant com- 
me des ports d'entree, pour lesdits sous-reseaux, 

dans lequel une ou plusieurs des passerelles 
(35, 39) reliant les sous-reseaux (31 , 34) con- 
serve^) une table d'acheminement (MURT) 
vers les postes recepteurs de destinations mul- 
tiples, 

et une en-tete, incluse dans chaque message 
a destinations multiples ayant ete transmis, 
comprend une information (group id) definis- 
sant un groupe desdits postes recepteurs de 
destinations multiples. 

2. Le procede selon la revendication 1 , dans lequel la 
table d'acheminement (MURT) cfune passerelle 
contient, en particulier en plus de ('information 
d'acheminement classique, un ou plusieurs identi- 
ficateur(s) de groupe (groupid) definissant au moins 
un poste recepteur de destinations multiples, de 
preference un groupe de postes r6cepteurs de des- 
tinations multiples, et un prefixe identifiant le ou les 
sous-reseau(x) dans lesquels le ou les poste(s) re- 
ceptees) de destinations multiples est/sont situe 
(s). 
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Le procede selon la revendication 2, dans lequel le 
ou les postes recepteur(s) ayant ete definis Fiden- 
tificateur de groupe (groupid) est/sont situe(s) dans 
des sous-reseaux differents. ss 

Le procede selon une ou plusieurs des revendica- 
tions precedentes, dans lequel les tables d'achemi- 



nement (MURT) conservees dans une passerelle 
particuliere comprennent une information seule- 
ment concernant les postes recepteurs de destina- 
tions multiples pouvanl etre atteints via ladite pas- 
serelle. 

Le procede selon Tune ou plusieurs des revendica- 
tions precedentes, dans lequel seules les passerel- 
les connectees a des sources possibles de messa- 
ges a destinations multiples conservent une table 
(MURT) des postes recepteurs a destinations mul- 
tiples adressables. 

Le procede selon I'uneou plusieurs des revendica- 
tions precedentes, dans lequel ('identification de 
groupe (groupid) et/ou les prefixes d'adresse sont 
transmis aux passerelles, conjointement avec re- 
formation d'acheminement classique. 

Un procede d'acheminement a destinations multi- 
ples d'un message depuis un poste emetteur a une 
pluralrte de postes recepteurs se trouvant dans un 
reseau de transmission de messages a une seule 
machine, classique, par utilisation de protocoles 
existants, ledit reseau etant constitue d'une plurali- 
te de sous-r6seaux comprenant des noeuds (pas- 
serelles A....E). dans lequel : 

une ou plusieurs passerelles (37... 39) reliant 
lesdits sous-reseaux (31. ..34) comprennent 
une table d'acheminement destin6e a des pos- 
tes r6cepteurs de destinations multiples, 

chaque message de destinations multiples a 
transmettre porte une en-tete comprenant une 
information definissant un groupe de postes re- 
cepteurs de destinations multiples, 

des moyens sont prevus dans chaque passe- 
relle pour interpreter, comparer et modifier Fen- 
tete du message de destinations multiples. 

Le systems selon la revendication 7, dans lequel 
les sous-reseaux sont de type differents et/ou font 
utilisation de protocoles de transmission de messa- 
ges differents. 

Le systeme selon la revendication 8, dans lequel 
seul un sous-jeu des sous-reseaux est equipe pour 
supporter I'acheminement a destinations multiples. 
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